A great variety of devices exist which provide data and/or communication capabilities. One of the most common devices for transmitting and receiving data is a computer. Computers include conventional desk top and lap-top computers as well as Personal Digital Assistants (PDAs) and other hand held devices, such as the Palm Pilot PocketPC, and Visor. Other types of devices are also used to transmit and receive data. For instance, some mobile radiotelephones and two way pagers not only provide voice communication capabilities but also enable the transfer and receipt of text messages and can be used to surf the Internet. In addition to mobile radiotelephones and pagers, enhanced television, WebTV, and other interactive television devices provide data capabilities in addition to displaying television programs. These devices are just some examples of devices which are currently available and which can communicate with other devices.
To enable communications between any two devices, a protocol is employed which defines the manner in which the two devices can communicate. In fact, in a network of devices, a plurality of protocols may be employed at various layers within the network. These layers include the physical layer, the data link layer, network layer, transport layer, session layer, presentation layer, and application layer. For instance, depending the particular layers, the protocol can govern the transmission of bits, handle errors in transmission, define routing of messages within a network, ensure reliability of transmissions, or define the format of the message.
A common protocol associated with the Internet is the Hyper Text Transfer Protocol (HTTP). HTTP is an application layer protocol that allows devices to transfer information over the Internet. For example, web browsers and servers operate HTTP and allow a user to access the World Wide Web (WWW) and a content provider to offer information to end users through a web site in the WWW. HTTP is not specific to any language, although most content providers use hyper-text mark-up language (HTML). Thus, HTTP also encompasses the Wireless Application Protocol (WAP) browsers and servers. For WAP devices, however, the devices use wireless mark-up language (WML) as opposed to HTML.
HTTP is a transactional protocol, meaning that it is based on requests from a client, such as a web browser, and responses from a server, such as a web server. With reference to FIG. 1, a client sends a request to a server with this request identifying a method and a universal resource locator (URL). The server receives the request and processes the URL, such as by obtaining information associated with the URL. For each request from a client, there is a response from the server. Thus, if the request was a request for data associated with a URL, the server would respond by obtaining that data and sending it to the client. The requests include reading a web page, submitting a form, etc. As can be seen from FIG. 1, HTTP is very well defined, has a very simple syntax, and provides a foundation upon which applications can be built to provide services.
Servers may have a number of HTTP applications. Often, content providers need to offer services through their content servers, be it a simple application that will collect feedback from visitors, or a more complex one like a shopping cart or an e-commerce application. All these applications share a common interface based on HTTP that allows a remote client to interact with the underlying resources, such as files, databases, etc., via a web browser. These applications are called HTTP applications, and often are referred to as WWW or Web Applications. Information is passed to HTTP applications in the request, usually setting parameters or cookies with the information provided by the user when filling in a form.
FIG. 2 shows an example web page and its corresponding HTML. The background of this figure depicts a form, a questionnaire, available from a server hosting the domain with the URL http://www.s21sec.com/caste/cuestionario/cuestionario.htm. When a client enters this URL or selects a link associated with the URL, the request is routed to the server, the server retrieves content associated with that URL and possibly performs some additional actions, and then routes a response back to the client. This response includes the html depicted in the notepad. The client browser interprets the html and renders the interface shown in the background.
The HTTP application receives the parameters and process them, sending a response back to the client with the result of the processing. HTTP applications do not depend on the programming languages, just in the interface (HTTP). A HTTP application can therefore be coded in any language, such as but not limited to C, C++, Visual Basic, Perl, or Java. There are well-known mechanisms of interacting with HTTP, such as Common Gateway Interface (CGI), Active Server Pages (ASP), Servlets, PHP, etc, but all of them rely on HTTP for communication between the client and the application.
A network environment is beneficial in that devices can communicate with each other but it exposes the devices and systems connected to the network to security risks. Network security is often regarded as protecting network resources from being accessed to ultimately prevent break-ins into company systems. A firewall is commonly located between the network and a company's system in order to prevent such break-ins. When installing a firewall, a main concern is to filter out ports that could be vulnerable to attacks from the outside.
As mentioned above, HTTP applications enable devices to gain access to a server's resources. For instance, HTTP applications may involve some kind of interaction between the end user and the backend of the company, be it a database server, file access to the server or just access to an email server. These HTTP applications consequently need privileges over these resources so that they can pass through the firewall, access the database, interact with the underlying operation system, etc. Because HTTP applications can provide access to sensitive areas of a company's system, a malicious user can subvert a vulnerable HTTP application and break into the company's resources and compromise their complete business.
A firewall may be ineffective in stopping such attacks. HTTP applications use the same network resources used by content servers, in fact they delegate on the web server to handle network transactions. As long as you need to offer HTTP access to any server, no current firewall can stop a HTTP application level attack. A traditional firewall works at the network and transport layers, but does not offer any kind of application protection. For example, FIG. 3 shows a diagram of a typical firewall 10 installed within a network. The firewall 10 is positioned between a server 12 and clients 8. The firewall 10 provides security to the server 12 on the Telnet and HTTP layers but does not offer any protection to an HTTP application 14.
A traditional approach to application security has been source code review and auditing. Source code review occurs after an application has been finished and involves having someone, often a third party, reviewing all the code and fixing any security problems that are discovered. This process is a never-ending task, as the auditor can overlook security bugs that will end up in the reviewed application, so it is not an assurance of full security. As more and more complex applications are being developed and the time-to-market shrinks in order to be the first to offer a service to customers, source code review is no longer an option, as freezing the deployment of an application for days or weeks means lost of business and revenue. A need therefore exists for systems and methods of providing security in a network, especially with HTTP applications.